Subject: TPF Prioritisation (on a different note)

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Fri, 15 Sep 95 10:22:09 EDT

Dave Finnie has identified the following problem:

>One of our customers has an environment where multiple PUs (aka LSs)
>share the same line (aka port). It is multi-dropped SDLC in the
>example, but the problem we have would apply equally to LANs, etc.
>
>We have implemented the suggested 4 queues per instance of PC, and we
>weight the transmissions progressively in favour of the higher TPF
>values, with an aging mechanism.
>
>However, the customer has the situation whereby low priority traffic
>(batch file transfer) flows over one of the PUs sharing the line, and
>high priority interactive traffic over one of the other PUs sharing
>the line.
>
>While our algorithm works beautifully for servicing differing TPF
>value traffic on a PU basis, in this example the low priority traffic
>is getting as much service as the high priority traffic because the
>prioritisation does not extend to the line level.

The ATM-01 document for HPR/ATM states that there is a related problem in
the ATM environment.  There you need to consider not only the
transmission priority of competing links on the port but also the
reserved bandwidth of the competing links.  The following quote is from
ATM-01 section 2.10.1:

 Typically, when multiple logical links share a port, current DLCs do
 round-robin scheduling among the links; however, with such a design in
 the ATM environment, the advantages of segregating traffic on separate
 VCCs would be lost before the traffic entered the ATM network.
 When multiple VCCs use the same ATM port, DLC must respect the traffic
 contracts for the various VCCs.

Dave pointed out one possible solution:

>*An* obvious solution is to internally extend the queues down to the
>line level, but I wanted to see if other implementers had addressed
>this issue, and what their preferred solutions were.

This is not sufficient in the ATM environment, where scheduling
between the links (i.e., virtual circuits) is also required to meet
negotiated traffic contracts.

Dave also asked the following question:

>Also... does the AIW forum feel that a consistent weighting and aging
>mechanism be employed by all APPN implementations (which choose to
>implement it) ? ie should we discuss *a* solution so that we have some
>point in which to start ? My reasoning is that an APPN network of
>heterogeneous implementations could become difficult to tune if all
>implementions do different things in this area. I'm prepared to throw
>our algorithm in as a starting point if this is seen to be a useful
>thing to pursue.

This would be a change to the architecture of record.  The APPN
Architecture Reference states that the aging mechanism is an
implementation choice.  See "Transmission Priority (Internode Path
Control Only)" on pp. 10-21 and 10-22.

Gary Dudley
IBM APPN Architecture Team

---

From: Dave Finnie <[email-masked]>
Date: Mon, 18 Sep 1995 10:52:06 +1000

Gary,

> negotiated traffic contracts.

Yes, I agree. I gather that you are saying that perhaps we should
think about a more general solution that will solve both my TPF
problem and the broader ATM issues at the port ? Or am I puting words
into your E-mail ?

> Control Only)" on pp. 10-21 and 10-22.

Yes, that was the subject of my discussion. Clearly old nodes need to
be supported, but it seems to me that TPF prioritisation is a very
important aspect of the architecture. My personal feeling is that to
enable network administrators (and fancy network management
applications) to tune the network properly, there should be a
consistent treatment of TPF - including both the ratios of bias toward
higher TPF values, and the aging mechanism.

Dave